黑客通过这个方法绕过人脸识别，银行二三类户开户到底有多少风险？
点击上方蓝字关注数据玩家
昨天看到一篇文章《00后黑客入侵厦门银行App 注册Ⅱ、Ⅲ类户出售获利》
根据文中提到的线索，数据玩家找到了裁判文书原文（（2019）闽0203刑初890号）：
被告人田世纪通过软件抓包、PS身份证等非法手段，在厦门银行手机银行APP内使用虚假身份信息注册银行Ⅱ、Ⅲ类账户。其在注册账户过程中，先输入本人身份信息，待进行人脸识别步骤时，利用软件抓包技术将银行系统下发的人脸识别身份认证数据包进行拦截并保存。尔后，在输入开卡密码步骤，被告人田世纪将APP返回到第一步（上传身份证照片之步骤），输入伪造的身份信息，并再次进入到人脸识别之身份验证步骤，此时，其上传此前拦截下来的包含其本人的身份信息数据包，使系统误以为要比对其本人的身份信息，其遂用本人人脸通过银行系统人脸识别比对，使得成功利用虚假身份信息注册到银行账户。http://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=29920418df10460c9aabab140096bcc9
数据玩家尝试复现一下这个过程：
最终提交的报文应该长这样：
{ 模块A基本信息： { 姓名：黑客姓名 证件类型： 证件号：黑客证件号 手机号：黑客手机号 手机验证码：黑客手机号收到的验证码 身份证照片：黑客身份证照片 …… } 模块B人脸识别信息： { 黑客人脸识别加密数据 }}黑客第一次按自己身份提交了，自己的身份证和人脸识别比对通过，说明加密数据部分被服务器接受了，黑客把这部分加密数据截取下来，返回输入身份证的步骤，重新填写了伪造的信息，拼凑上截取的人脸识别加密数据，一并提交：
{ 模块A基本信息： { 姓名：伪造身份姓名 证件类型： 证件号：伪造身份证件号 手机号：伪造身份手机号 手机验证码：伪造身份手机号收到的验证码 身份证照片：伪造身份证照片 …… } 模块B人脸识别信息： { 黑客人脸识别加密数据 }}然后居然开户成功了，而且开的是伪造身份的账户。这是典型的中间人攻击+重放攻击。
经过复盘，数据玩家认为这里有几个环节没做好：
交易流程设计缺陷
人脸识别通常放在最后一步，因为这一步成本最高，失败率最高，客户体验最差，案例中人脸识别以后还有输入交易密码。
不放在最后一步没关系，但是人脸识别完成以后不能返回上一级，从体验角度讲，如果误触，这很可能需要正常用户再做一次人脸识别；从安全角度讲，有可能被截获报文进行重放攻击。
退一步讲，就算允许返回上一级，之前填的身份信息以及上传的身份证不应该还能修改，从体验角度讲增加用户重复输入的工作量；从安全角度讲，也留下了漏洞。
是否进行五要素验证？
提交基本信息后，应该进行五要素验证，为什么这里强调五要素？因为黑客使用的是伪造的身份信息，做了五要素验证，那至少这套伪造信息还开了个一类卡，反过来讲可以提高犯罪成本。
不过至少也做了四要素验证吧？手机验证码怎么破的？虽然工信部要求：
要求电信企业自2019年12月1日起在实体渠道全面实施人像比对技术措施，人像比对一致后方可办理入网手续 《工信部持续加强电话用户实名登记管理工作维护公民网络空间合法权益》
但是运营商网点的安全措施及开户严格程度，肯定比不了银行网点，而且有很多之前开的户，并不验证本人身份。甚至有可能，黑客引导受害者本人开了手机号然后整套身份卖给黑客。这还没提伪基站等其他手段，因此不能假设验证码是铁板一块。
所以，如果进行了五要素验证，则必须用受害者的身份开一张一类卡，而且预留受害者本人的手机号，这个成本大大增加了。当然不可能完全防范欺诈的可能，但是只要成本足够高，就能让黑客放弃攻击。
未能防止重放攻击
防止重放攻击其实是很基础的安全措施，只要使用不重数即可。
不重数即不重复的数，可能是随机数、流水号、交易时间等，最简单的，把所有的报文放一起做个交易签名，可以用哈希或者MD5的方式，把签名放在报文尾，服务器收到报文后，会再把交易按同样逻辑算一遍签名，如果和交易本身的能对上，说明报文没有被篡改。
当然，直接用哈希或者MD5，很容易被攻击者试出来，则可以伪造签名，因此签名需要加一个约定好的随机数（加盐）。
未进行通道加密
最基本的，客户端和服务端之间的所有通信，应该都是整体加密的，这是金融应用最基本的要求了。这里我不是很理解如何破解的，希望有安全专家释疑，或者事发银行当时根本没做通道加密……
人脸识别本地运算
按道理说，首次开户的人脸识别应该是要把摄像头采集的照片和公民联网核查（从公安部采集的高清网纹照）做比对的，而具体的身份信息，应该从模块A（参见上方代码）中实时获取，这种方式下，这个案例中的攻击方式是过不了检测的。
既然这方法成功了，说明可能这家机构的人脸识别是放在手机本地执行了，也就是说，第一次人脸识别的时候，手机客户端从服务器端获取了黑客本人的高清网纹照，和黑客手机摄像头采集的黑客本人照片做了比对，通过后的结果加密在一起上传，这个加密包被截获后，太容易重放攻击了。
因此，人脸识别这个动作，一定要在服务端进行，客户端只采集基本信息和人脸信息，如何比对，和谁比对，都应该由服务器端来判断。并且，按照最新的《个人金融信息保护技术规范》要求本地不能存储C3级别生物特征信息，每次使用后都必须删除，一定程度上也提醒金融机构不要把生物特征的运算也留在本地。
日常监控
这一点厦门银行应该还是做了，裁判文书显示，黑客于2019年1月5日至1月15日期间开了76个账户，应该是监控到了才报的警，因此日常的监控也很重要，有些漏洞是没法提前想到的，只能通过监控来查漏补缺。
单位时间内（小时、日、月），特定区域（手机定位、IP、手机号归属地），特定设备（设备号，设备指纹等）开户的数量需要纳入监控，防范虚假账户风险。这一层如果不防好，后续这些账户去做贷款就更麻烦了。
后记
II、III类账户给中小银行展业提供了诸多便利，但是也带来了诸多风险，这次案例是在手机银行App上，还进行了人脸识别，相对安全级别较高。还有很多银行，推广的阶段是在网页端就能开户，只需要四要素/五要素+一个手机验证码，这个网页通常还是由第三方渠道开发，投放在银行外的各类平台。为了获客，通常新户还有奖励。无论怎么看，风险都比案例中高很多，希望各银行也内部排查一下，看看线上开户环节到底有没有风险。
冒领个开户奖励倒还好，流转到信贷阶段，信贷反欺诈基本认为人脸识别是可信的，这些账户出现首逾时可能导致欺诈模型出现严重偏差。风险是累积的，也是全面的，这类开户风险，相比从事信贷风控的同事很难去防控，因此需要各部门协同，联防联控，共同应对各类已知和未知的风险。